Computers have been used for a number of purposes ranging, for example, from text document editing to distributed processing involving the transfer of data between data processing systems.
With a growing number of data processing devices having access to computer networks, such as to local area networks and world-wide networks, a growing number of computer programs are offered to users that use a plurality of data processing units. Such applications may be found, for example, in the fields of home banking, office applications, remote e-mail applications, and supercomputing applications. In corresponding data communications systems, high speed links, via permanent connections, circuit-switched connections or packet-switched connections are used to exchange digital data at high speed (and high-bit rates) such that data, including graphics data and data from moving images, can be exchanged among the data processing devices.
Data communications systems typically do not require that all participating data processing devices have the same processing capabilities, that is the same processing power. That is, a main computer having a high level of computing facilities can provide services to a number of less powerful computers through one or more of the above-described communication links. Since the less powerful computers are typically assigned the tasks of accessing the main computer and requesting processing facilities or data from the main computer while the main computer itself serves the data to the less powerful computers, the main computer is typically referred to as a server (or server unit) and the less powerful computers are typically referred to as clients (or client units). In such a scenario, a client requests the execution of an application program that resides on the server, and receives a data processing result or content data from the server via a network or communication link that connects the client and the server.
There are also systems in which a plurality of clients can connect to a portal for the execution of an application. A portal is a site on a network that includes a plurality of servers that provide a variety of services, including for example, office applications, searching functions, news functions, e-mail applications, discussion groups, on-line shopping and links to other sites on the network. The servers can be linked via back-end tunneling. A portal may thus be a general-purpose site offering the capability to perform applications on behalf of the client or to assist the clients in executing an application.
In a client and server or portal scenario, the server may be a large computing device that has sufficient resources to store and execute computer programs, which are used to provide services to the client. Since the computer programs and sufficient computing power are typically available at the server side, but typically not at the client side, the client may be a data processing unit with less powerful computing resources than the server. The client therefore typically functions as an interface to receive user commands required to execute a desired computer program on the server, to provide requests to the server (that is, to transmit commands from the client to the server), and to receive and display computation results from the server.
Conventional Server and Client Configuration
Referring to FIG. 1, FIG. 1 depicts a conventional data processing system 100. In FIG. 1, a server 102 and clients 104, 106, 108, 110, and 112 communicate through communication links 114 and 116, typically set up through a communication network 118 that can include the Internet. Communication network 118 includes, for example, an intranet 120 to which clients 104, 106, 108 are connected. As illustrated, clients can also be connected to server 102 without communicating via the Internet, such as client 110. An additional server 122 (as shown in dashed lines) can also be provided.
Communication link 114 illustrates that client 106 has sent a request for content data to server 102. These requests from the client for data are called content data request messages. The content data is returned from the server in a content data provision message. Although the request is received at server 102, the content data may be provided from server 122, which transmits the content data to server 102, for example, through a back-end tunnel.
FIG. 2 shows a more detailed block diagram of a conventional server 202 and a conventional client 204. Server 202 and client 204 communicate through communication link 206 connected to an interface 208 in server 202 and an interface 210 in client 204.
Client 204 typically comprises a content data request unit 212 (such as a browser) for sending content data request messages, a client processor 214, and a memory 216. A number of computer programs 218, such as a browser and a word processor, are in memory 216. Client 204 also comprises a display 220 and a page setting unit 222 for formatting pages. Page setting unit 222 can also be a browser.
Server 202 typically comprises a request message receiving unit 224 (such as a web server program) for receiving content data request messages, a server processing unit 226 including an Application Programming Interface 228, at least one data processing unit 230 (if server 202 uses Java™ technology, data processing unit 230 comprises, for example, one or more servlets or JavaServer™ pages), a content data providing unit 232 for sending content data provision messages, a local database 234 including content data 236 such as HTML web pages, and a special service provider 238 for providing a special service available on server 202. Special service provider 228 can be a web server program. A service is considered “special” when it is provided by one of the servers, and may not be provided by the others. For example, a server provides a special service when that server alone hosts a web page and contains the web page data. Sun Microsystems, Sun, the Sun logo, Java, JavaServer, portalconnect, portal, and GRIP are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Referring to FIG. 3, FIG. 3 depicts an example of typical operations that are carried out by client 204 and server 202 for the typical scenario shown in FIG. 1. These operations are described below.
Conventional Request/Provision of Content Data
Typical client and server operations include a client requesting content data from a server through a content data request message, and the server returning the requested content data in a content data provision message. In an example, a user at client 204 wants to access a web page document from server 202. The web page can be available at server 204 or at another location. First, the user selects one of client 204's programs 218 (step 302). The selected programs 218 is, for example, a browser that is executed at the client. When using the browser, the user clicks with a mouse pointer on a particular place on display 220 to retrieve a web page from the server. The content data request unit 212 sends a content data request message 240 requesting the web page data to server 202 (step 304). In accordance with the Internet protocol, content data request message 240 is typically an HTTP protocol message and requests the transfer of HTML pages from database 234 located within server 202 (or located elsewhere outside server 202). The HTTP request message includes the URL from which the HTML web pages should be retrieved and additional header information.
After setting up communication link 206 between client 204 and server 202, server 202 receives content data request message 240 (step 306). Client 204 can also request sever 202 to execute processing programs 230 that are located on the server, such as servlets.
Server processing unit 226 together with content data providing unit 232 statically or dynamically retrieve the requested content data, that is the HTML web pages (step 308). In a static retrieval, server processing unit 226 accesses local database 234 and retrieves the HTML web pages. In a dynamic retrieval, server processing unit 226 runs additional programs, such as servlets 230, to retrieve or generate data from a remote site in a dynamic manner, such as from remote server 122. For these operations, server processing unit 226 uses Application Programming Interface (API) 228 for coordinating which servlets 230 are used. Server processing unit 226 then determines which page format to use for client 204, that is the MIME-Type (step 310).
Content data providing unit 232 of server 202 then provides, through communication link 206, the retrieved or generated content data or instruction data set to client 204 in a content data provision message 242 (step 312).
Client 204 then receives content data provision message 242 from server 202 (step 314). Responsive to a user selection, client 204 then displays the received content data on display 220, stores it on a disc, or prints it out on a printer (step 316).
If the requested content data includes web-page data (e.g., HTML web pages), client 204 typically requests complete data sets relating to one page, which are transferred from server 202. Therefore, client 204 then determines if the user requires further web pages, that is further content data, from server 202 (step 318). If client 204 determines that further pages are required, processing returns to step 304. If client 204 determines that no further pages are required, client 204 closes communication link 206 after some time, for example, by stopping the browser (step 320).
As described above in step 308, server 202, which has received content data request message 240 in step 306, attempts to retrieve or generate the requested content data statically or dynamically. For example, if server 202 is to retrieve or generate content data from a special service contained in special service provider 238 of server 202, then server 202 can generate the content data “locally at server 202. The requested content data from a special service provider, however, typically resides elsewhere on network 118. For example, the desired content data can reside on server 122. In this case, server 202 uses dynamic retrieval and generation of the content data. In doing so, the first addressed server 202 communicates with the additional server 122 before returning the content data to client 204 in step 312.
Use of a Load Balancer for Routing Messages
Referring to FIGS. 4a and 4b, a data processing system 400 has a number of servers 402, 404, 406, and 408 and a number of clients 410, 412, 414, and 416. Each of the servers is similar to server 202 shown in FIG. 2. And each of the clients is similar to client 204 of FIG. 2. Accordingly, the item numbers of FIG. 2 are used to designate similar elements in FIG. 4. The servers and clients communicate via communication network 418 that includes a client network 420, such as an intranet, on the client side of network 418 and a server network 422, such as another intranet, on the server side. The servers can also communicate with each other via a back end tunnel 424.
The clients send content data request messages 430 over communication network 418 to the servers. En route, the content data request messages arrive at load balancer 426, which distributes the content data request messages to individual servers on the server network. In FIGS. 4a and 4b, communication network 418 is shown for illustrative purposes between the clients and the load balancer. It should be understood, however, that communication network 418 may also have parts existing between the load balancer and the servers.
The load balancer comprises a load determining unit 432 for determining the server's processing loads, a message distribution unit 434 for distributing received messages to the clients and servers, and a balancer control unit 436. The balancer control unit 436 controls load determining unit 432 and message distribution unit 434, which distributes the content data request messages from the plurality of clients to the plurality of servers dependent on the processing loads of said individual servers.
The servers return content data provision messages 438 via the load balancer to the respective clients in response to the content data request messages sent from the clients.
Considering that the data processing system of FIGS. 4a and 4b has a large number of clients and a large number of servers exchanging content data request and provision messages, the load balancer's load balancing function is typically necessary to avoid servers from becoming overloaded with content data request messages, which could delay server response times. Therefore, even if client 412 issues a content data request message requesting content data from special service unit 440 in server 404 (that is from a particular server), the load balancer may route this content data request message to server 402 instead, because server 402 may have a smaller processing load than server 404 at that time. In this case, the servers may establish a back end tunnel between server 402 and server 404 to retrieve the content data from the special service unit 440 in server 404. However, it is server 402 that will return the requested content data to client 412.
FIG. 5 illustrates a flow chart in which the typical operations of FIG. 3 are extended to include the use of a load balancer. Referring to FIG. 5, first, client 410 receives user input to execute one of client 410's programs, such as a browser program (step 502). This is done in a manner similar to step 302 described above with reference to FIG. 3. When the user clicks with a mouse pointer on a particular place on display 220 of client 410, content data request unit 212 of client 410 sends a content data request message 430 to server 408, requesting for example web page data (step 504).
The load balancer receives the content data request message before it arrives at a particular server, and determines which server is to receive the content data request message in accordance with the processing load of each server (step 506). The server identified by the load balancer as having a small enough processing load to receive the content data request message, namely server 402, then receives the issued content data request message from the load balancer (step 508). Then, server 402 retrieves the requested content data from the location where the desired content data resides, namely from server 404 (step 510). As illustrated in FIG. 5, server 402 can retrieve the requested content data from server 404 through the use of the back end tunnel.
Server 402 then determines which page format to use for client 410, such as the MIME-Type (step 512). Content data providing unit 232 of server 402 then provides, through communication network 418, the retrieved or generated content data or instruction data set to client 410 via the load balancer in content data provision message 438 (step 514).
Client 410 then receives content data provision message 438 with the content data or instruction data set from the load balancer (step 516). Responsive to a user selection, client 410 can then display the received content data on display 220 of client 410, store it on a disc, or print it out on a printer (step 518).
If the requested content data is web page data (e.g., HTML web pages), client 410 typically requests complete data sets relating to one page, which are then transferred from server 402 to client 410. Client 410 then determines if the user requires further web pages, that is data sets, from server 402 (step 520). If client 410 determines that further web pages are required, processing returns to step 504. If client 410 determines that no further web pages are required, client 410 closes communication to server 402 after some time, for example, by stopping the browser (step 522).
Disadvantages of the Use of the Load Balancer
As described above, the use of a load balancer, with its load balancing functionality, can assist particular servers from becoming overloaded with data content request messages. When the data content request message is implemented in a communication protocol that does not care which server returns the content data, the load balancing functionality does not present a problem. In an example, the content data request message is implemented in the HTTP protocol and requests an HTML web page from a database located within a server. The message contains the URL from which the HTML web page should be retrieved. Using the URL, the data will be retrieved from the correct site. However, as a result of the use of the load balancer, the message may still be diverted to another server.
On the other hand, a client might want the data content request message directed to a particular server that has the content data or special service, instead of being first directed to another server due to load balancing. This situation arises when the request message is implemented in a communication protocol that specifies that messages for a particular client should be sent to a particular server. In such a communication protocol implementation, such as portalconnect™ protocol (also known as portal™ protocol), the content data request message contains a user field including identification information of the user and/or client and an identification of the special service unit from which content data is to be retrieved. Another protocol used for this purpose is Generic Interconnect Protocol (GRIP™) protocol. Portalconnect, portal, and GRIP are trademarks or registered trademarks of Sun Microsystems, Inc., Palo Alto, Calif.
Load balancers, however, do not typically allow for the detection of such a user field transmitted in the data stream, and therefore the load balancers cannot direct traffic to the desired host. Instead, the severs tunnel the requested data on the server back end in the typical manner, as described above with reference to FIGS. 4a and 4b. Further, the load balancers might not be able to read the user field, as is the case when the load balancer cannot read the communication protocol implementation of the request message.
Therefore, products that require particular communication paths during message exchange are hindered by typical load balancers. That is, if traffic from a particular client is to be directed to a particular server, the load balancer, which normally provides an even load distribution among servers, will typically ignore the desired effect.